GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>HTTP-Statuscode</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading">HTTP-Statuscode</h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr">Ein HTTP-Statuscode wird von einem <a href="Server" title="Server">Server</a> auf jede <a href="Hypertext_Transfer_Protocol" title="Hypertext Transfer Protocol">HTTP</a>-Anfrage als Antwort geliefert. Auf der anfragenden Seite steht dabei ein <a href="Client" title="Client">Client</a> wie beispielsweise ein <a href="Webbrowser" title="Webbrowser">Webbrowser</a>. Der Server teilt durch den HTTP-Statuscode dem Client mit, ob die Anfrage erfolgreich bearbeitet wurde. Im Fehlerfall gibt der Statuscode Auskunft darüber, wo (beispielsweise über eine Umleitung) oder wie (zum Beispiel mit <a href="HTTP-Authentifizierung" title="HTTP-Authentifizierung">Authentifizierung</a>) er die gewünschten Informationen erhalten kann. Am bekanntesten sind dabei die Codes 404: „Nicht gefunden“, 403: „Fehlende Zugriffsberechtigung“ und 400: „Fehlerhafte Anfrage“.

Die erste Ziffer eines Statuscodes stellt die Statusklasse dar. Sie sind in RFC 9110<a href="#cite_note-1">[1]</a> (ersetzt RFC 2616<a href="#cite_note-RFC2616-2">[2]</a>), sowie RFC 2518,<a href="#cite_note-RFC2518-3">[3]</a> RFC 2817,<a href="#cite_note-RFC2817-4">[4]</a> RFC 2295,<a href="#cite_note-RFC2295-5">[5]</a> RFC 2774<a href="#cite_note-RFC2774-6">[6]</a> und RFC 4918<a href="#cite_note-RFC4918-7">[7]</a> spezifiziert. Einige gehören zum <a href="WebDAV" title="WebDAV">Distributed Authoring (WebDAV)</a>.

Neben den in <a href="Request_for_Comments" title="Request for Comments">RFC</a> standardisierten Statuscodes verwenden manche Softwarehersteller auch <a href="Propriet%C3%A4r" title="Proprietär">proprietäre</a> Codes für eigens definierte Status- und Fehlermeldungen. Andere Software kann dem Benutzer diese Codes nur als allgemeinen unbekannten Fehler anzeigen; nicht aber eine Übersetzung und Hinweise zum weiteren Vorgehen. Teilweise können die Server den Begleitumständen der Anfrage bereits entnehmen, dass es sich um die zugehörige Spezialsoftware handelt, und geben nur dann die proprietären Codes zurück. In diesem Artikel sind einige proprietäre Codes aufgeführt und entsprechend gekennzeichnet.

<div class="mw-heading mw-heading2"><h2 id="Liste_der_HTTP-Statuscodes">Liste der HTTP-Statuscodes</h2></div>

<div class="mw-heading mw-heading3"><h3 id="1xx_–_Informationen"> 1xx – Informationen</h3></div>

Die Bearbeitung der Anfrage dauert noch an.

<th>Code

</th>

<th>Nachricht

</th>

<th>Bedeutung

</th></tr>

<th>100

</th>

<td>Continue

</td>

<td>Die laufende Anfrage an den Server wurde noch nicht zurückgewiesen. (Wird im Zusammenhang mit dem „Expect 100-continue“-Header-Feld verwendet.<a href="#cite_note-RFC2616-2">[2]</a>) Der Client kann nun mit der potentiell sehr großen Anfrage fortfahren.

</td></tr>

<th>101

</th>

<td>Switching Protocols

</td>

<td>Wird verwendet, wenn der Server eine Anfrage mit gesetztem „Upgrade“-Header-Feld empfangen hat und mit dem Wechsel zu einem anderen Protokoll einverstanden ist. Anwendung findet dieser Status-Code beispielsweise im Wechsel von HTTP zu <a href="WebSocket" title="WebSocket">WebSocket</a>.

</td></tr>

<th>102

</th>

<td>Processing

</td>

<td>Wird verwendet, um ein Timeout zu vermeiden, während der Server eine zeitintensive Anfrage bearbeitet.<a href="#cite_note-RFC2518-3">[3]</a> Dies ist eine Interim-Antwort, auf die auf derselben Verbindung ohne weitere Client-Anfrage eine endgültige Antwort folgen muss.

</td></tr>

<th>103

</th>

<td>Early Hints

</td>

<td>Wird zusammen mit dem „Link“-Header verwendet, um das Vorladen von Ressourcen zu ermöglichen, während der Server die finale Antwort noch vorbereitet.<a href="#cite_note-8">[8]</a>

</td></tr></tbody></table>

<div class="mw-heading mw-heading3"><h3 id="2xx_–_Erfolgreiche_Operation"> 2xx – Erfolgreiche Operation</h3></div>

Die Anfrage war erfolgreich, die Antwort kann verwertet werden.

<th>Code

</th>

<th>Nachricht

</th>

<th>Bedeutung

</th></tr>

<th>200

</th>

<td>OK

</td>

<td>Die Anfrage wurde erfolgreich bearbeitet und das Ergebnis der Anfrage wird in der Antwort übertragen.

</td></tr>

<th>201

</th>

<td>Created

</td>

<td>Die Anfrage wurde erfolgreich bearbeitet. Die angeforderte Ressource wurde vor dem Senden der Antwort erstellt. Das „Location“-Header-Feld enthält eventuell die Adresse der erstellten Ressource.

</td></tr>

<th>202

</th>

<td>Accepted

</td>

<td>Die Anfrage wurde akzeptiert, wird aber zu einem späteren Zeitpunkt ausgeführt. Das Gelingen der Anfrage kann nicht garantiert werden.

</td></tr>

<th>203

</th>

<td>Non-Authoritative Information

</td>

<td>Der Server agiert als „Transforming <a href="Proxy_(Rechnernetz)" title="Proxy (Rechnernetz)">Proxy</a>“, erhielt eine 200 OK Antwort von der Quelle und antwortet mit einem veränderten Dokument der Quelle.<a href="#cite_note-9">[9]</a><a href="#cite_note-10">[10]</a>

</td></tr>

<th>204

</th>

<td>No Content

</td>

<td>Die Anfrage wurde erfolgreich durchgeführt, die Antwort enthält jedoch bewusst keine Daten.

</td></tr>

<th>205

</th>

<td>Reset Content

</td>

<td>Die Anfrage wurde erfolgreich durchgeführt; der Client soll das Dokument neu aufbauen und Formulareingaben zurücksetzen.

</td></tr>

<th>206

</th>

<td>Partial Content

</td>

<td>Der angeforderte Teil wurde erfolgreich übertragen (wird im Zusammenhang mit einem „Content-Range“-Header-Feld oder dem Content-Type multipart/byteranges verwendet). Kann einen Client über Teil-Downloads informieren (wird zum Beispiel von <a href="Wget" title="Wget">Wget</a> genutzt, um den Downloadfortschritt zu überwachen oder einen Download in mehrere Streams aufzuteilen).

</td></tr>

<th>207

</th>

<td>Multi-Status

</td>

<td>WebDAV RFC 4918<a href="#cite_note-RFC4918-7">[7]</a> – Die Antwort enthält ein in WebDAV spezifiziertes XML-Dokument, das mehrere Statuscodes zu unabhängig voneinander durchgeführten Operationen enthält.

</td></tr>

<th>208

</th>

<td>Already Reported

</td>

<td>WebDAV RFC 5842,<a href="#cite_note-RFC5842-11">[11]</a> – Die Mitglieder einer WebDAV-Bindung wurden bereits zuvor aufgezählt und sind in dieser Anfrage nicht mehr vorhanden.

</td></tr>

<th>226

</th>

<td>IM Used

</td>

<td>RFC 3229<a href="#cite_note-12">[12]</a> – Der Server hat eine GET-Anforderung für die Ressource erfüllt, die Antwort ist eine Darstellung des Ergebnisses von einer oder mehrerer Instanz-Manipulationen, bezogen auf die aktuelle Instanz.

</td></tr></tbody></table>

<div class="mw-heading mw-heading3"><h3 id="3xx_–_Umleitung"> 3xx – Umleitung</h3></div>

Um eine erfolgreiche Bearbeitung der Anfrage sicherzustellen, sind weitere Schritte seitens des Clients erforderlich.

<th>Code

</th>

<th>Nachricht

</th>

<th>Bedeutung

</th></tr>

<th>300

</th>

<td>Multiple Choices

</td>

<td>Die angeforderte Ressource steht in verschiedenen Arten zur Verfügung. Die Antwort enthält eine Liste der verfügbaren Arten. Das „Location“-Header-Feld enthält eventuell die Adresse der vom Server bevorzugten Repräsentation.

</td></tr>

<th>301

</th>

<td>Moved Permanently

</td>

<td>Die angeforderte Ressource steht ab sofort unter der im „Location“-Header-Feld angegebenen Adresse bereit (auch Redirect genannt). Die alte Adresse ist nicht länger gültig.

</td></tr>

<th>302

</th>

<td>Found (Moved Temporarily)

</td>

<td>Die angeforderte Ressource steht vorübergehend unter der im „Location“-Header-Feld angegebenen Adresse bereit.<a href="#cite_note-13">[13]</a> Die alte Adresse bleibt gültig. Die Browser folgen meist mit einem GET, auch wenn der ursprüngliche Request ein POST war. Wird in HTTP/1.1 je nach Anwendungsfall durch die Statuscodes 303 oder 307 ersetzt. 302-Weiterleitung ist aufgrund eines Suchmaschinen-Fehlers, des <a href="URL-Hijacking" title="URL-Hijacking">URL-Hijackings</a>, in Kritik geraten.

</td></tr>

<th>303

</th>

<td>See Other

</td>

<td>Die Antwort auf die durchgeführte Anfrage lässt sich unter der im „Location“-Header-Feld angegebenen Adresse beziehen. Der Browser soll mit einem GET folgen, auch wenn der ursprüngliche Request ein POST war.

</td></tr>

<th>304

</th>

<td>Not Modified

</td>

<td>Der Inhalt der angeforderten Ressource hat sich seit der letzten Abfrage des Clients nicht verändert und wird deshalb nicht übertragen. Zu den Einzelheiten siehe <a href="Browser-Cache#Versionsvergleich" title="Browser-Cache">Browser-Cache-Versionsvergleich</a>.

</td></tr>

<th>305

</th>

<td>Use Proxy

</td>

<td>Die angeforderte Ressource ist nur über einen Proxy erreichbar. Das „Location“-Header-Feld enthält die Adresse des Proxys.

</td></tr>

<th>306

</th>

<td>(reserviert)

</td>

<td>306 wird nicht mehr verwendet, ist aber reserviert. Es wurde für „Switch Proxy“ verwendet.

</td></tr>

<th>307

</th>

<td>Temporary Redirect

</td>

<td>Die angeforderte Ressource steht vorübergehend unter der im „Location“-Header-Feld angegebenen Adresse bereit. Die alte Adresse bleibt gültig. Der Browser soll mit derselben Methode folgen wie beim ursprünglichen Request (d. h. einem POST folgt ein POST). Dies ist der wesentliche Unterschied zu 302/303.

</td></tr>

<th>308

</th>

<td>Permanent Redirect

</td>

<td>Die angeforderte Ressource steht ab sofort unter der im „Location“-Header-Feld angegebenen Adresse bereit, die alte Adresse ist nicht länger gültig. Der Browser soll mit derselben Methode folgen wie beim ursprünglichen Request (d. h. einem POST folgt ein POST). Dies ist der wesentliche Unterschied zu 301.<a href="#cite_note-14">[14]</a>

</td></tr></tbody></table>

<div class="mw-heading mw-heading3"><h3 id="4xx_–_Client-Fehler"> 4xx – Client-Fehler</h3></div>

Die Ursache des Scheiterns der Anfrage liegt (eher) im Verantwortungsbereich des Clients.

<th>Code

</th>

<th>Nachricht

</th>

<th>Bedeutung

</th></tr>

<th>400

</th>

<td>Bad Request

</td>

<td>Die Anfrage-Nachricht war fehlerhaft aufgebaut.

</td></tr>

<th>401

</th>

<td>Unauthorized

</td>

<td>Die Anfrage kann nicht ohne gültige Authentifizierung durchgeführt werden. Wie die Authentifizierung durchgeführt werden soll, wird im „WWW-Authenticate“-Header-Feld der Antwort übermittelt.

</td></tr>

<th>402

</th>

<td>Payment Required

</td>

<td>Bezahlung benötigt. Dieser Status ist für zukünftige HTTP-Protokolle reserviert.

</td></tr>

<th>403

</th>

<td>Forbidden

</td>

<td>Die Anfrage wurde mangels Berechtigung des Clients nicht durchgeführt, bspw. weil der authentifizierte Benutzer nicht berechtigt ist oder ein als HTTPS konfigurierter URL nur mit HTTP aufgerufen wurde.

</td></tr>

<th>404

</th>

<td>Not Found

</td>

<td>Die angeforderte Ressource wurde nicht gefunden. Dieser Statuscode kann ebenfalls verwendet werden, um eine Anfrage ohne näheren Grund abzuweisen. Links, die auf solche Fehlerseiten verweisen, werden auch als <a href="Toter_Link" title="Toter Link">Tote Links</a> bezeichnet. „404“ gilt zudem als verbreitetes <a href="Meme_(Kulturph%C3%A4nomen)" title="Meme (Kulturphänomen)">Meme</a>.

</td></tr>

<th>405

</th>

<td>Method Not Allowed

</td>

<td>Die Anfrage darf nur mit anderen HTTP-Methoden (zum Beispiel GET statt POST) gestellt werden. Gültige Methoden für die betreffende Ressource werden im „Allow“-Header-Feld der Antwort übermittelt.

</td></tr>

<th>406

</th>

<td>Not Acceptable

</td>

<td>Die angeforderte Ressource steht nicht in der gewünschten Form zur Verfügung. Gültige „Content-Type“-Werte können in der Antwort übermittelt werden.

</td></tr>

<th>407

</th>

<td>Proxy Authentication Required

</td>

<td>Analog zum Statuscode 401 ist hier zunächst eine Authentifizierung des Clients gegenüber dem verwendeten Proxy erforderlich. Wie die Authentifizierung durchgeführt werden soll, wird im „Proxy-Authenticate“-Header-Feld der Antwort übermittelt.

</td></tr>

<th>408

</th>

<td>Request Timeout

</td>

<td>Innerhalb der vom Server erlaubten Zeitspanne wurde keine vollständige Anfrage des Clients empfangen.

</td></tr>

<th>409

</th>

<td>Conflict

</td>

<td>Die Anfrage wurde unter falschen Annahmen gestellt. Im Falle einer PUT-Anfrage kann dies zum Beispiel auf eine zwischenzeitliche Veränderung der Ressource durch Dritte zurückgehen.

</td></tr>

<th>410

</th>

<td>Gone

</td>

<td>Die angeforderte Ressource wird nicht länger bereitgestellt und wurde dauerhaft entfernt.

</td></tr>

<th>411

</th>

<td>Length Required

</td>

<td>Die Anfrage kann ohne ein „Content-Length“-Header-Feld nicht bearbeitet werden.

</td></tr>

<th>412

</th>

<td>Precondition Failed

</td>

<td>Eine in der Anfrage übertragene Voraussetzung, zum Beispiel in Form eines „If-Match“-Header-Felds, traf nicht zu.

</td></tr>

<th>413

</th>

<td>Payload Too Large

</td>

<td>Die gestellte Anfrage war zu groß, um vom Server bearbeitet werden zu können. Ein „Retry-After“-Header-Feld in der Antwort kann den Client darauf hinweisen, dass die Anfrage eventuell zu einem späteren Zeitpunkt bearbeitet werden könnte.

</td></tr>

<th>414

</th>

</td>

<td>Die <a href="Uniform_Resource_Identifier" title="Uniform Resource Identifier">URI</a> bzw. <a href="Uniform_Resource_Locator" title="Uniform Resource Locator">URL</a> der Anfrage war zu lang. Ursache ist oft eine Endlosschleife aus Redirects.

</td></tr>

<th>415

</th>

<td>Unsupported Media Type

</td>

<td>Der Inhalt der Anfrage wurde mit ungültigem oder nicht erlaubtem Medientyp übermittelt.

</td></tr>

<th>416

</th>

<td>Range Not Satisfiable

</td>

<td>Der angeforderte Teil einer Ressource war ungültig oder steht auf dem Server nicht zur Verfügung.

</td></tr>

<th>417

</th>

<td>Expectation Failed

</td>

<td>Verwendet im Zusammenhang mit einem „Expect“-Header-Feld. Das im „Expect“-Header-Feld geforderte Verhalten des Servers kann nicht erfüllt werden.

</td></tr>

<th>421

</th>

<td>Misdirected Request

</td>

<td>Die Anfrage wurde an einen Server gesendet, der nicht in der Lage ist, eine Antwort zu senden. Eingeführt in <a href="HTTP/2" class="mw-redirect" title="HTTP/2">HTTP/2</a>.

</td></tr>

<th>422

</th>

<td>Unprocessable Entity

</td>

<td>Verwendet, wenn weder die Rückgabe von Statuscode 415 noch 400 gerechtfertigt wäre, eine Verarbeitung der Anfrage jedoch zum Beispiel wegen <a href="Semantik" title="Semantik">semantischer</a> Fehler abgelehnt wird.<a href="#cite_note-RFC4918-7">[7]</a>

</td></tr>

<th>423

</th>

<td>Locked

</td>

<td>Die angeforderte Ressource ist zurzeit gesperrt.<a href="#cite_note-RFC4918-7">[7]</a>

</td></tr>

<th>424

</th>

<td>Failed Dependency

</td>

<td>Die Anfrage konnte nicht durchgeführt werden, weil sie das Gelingen einer anderen Anfrage voraussetzt.<a href="#cite_note-RFC4918-7">[7]</a>

</td></tr>

<th>425

</th>

<td>Too Early

</td>

<td>Der Server bittet den Client die Anfrage erneut zu senden, da die TLS-Verbindung noch nicht vollständig hergestellt wurde.<a href="#cite_note-16">[16]</a> Dies soll einen <a href="Replay-Angriff" title="Replay-Angriff">Replay-Angriff</a> verhindern.

</td></tr>

<th>426

</th>

<td>Upgrade Required

</td>

<td>Der Server verlangt vom Client, dass er die Anfrage mit einem anderen Protokoll wiederholt.<a href="#cite_note-17">[17]</a> Ein Anwendungsfall ist das Umschalten auf HTTP mit Transport Layer Security.<a href="#cite_note-RFC2817-4">[4]</a>

</td></tr>

<th>428

</th>

<td>Precondition Required

</td>

<td>Für die Anfrage waren nicht alle Vorbedingungen erfüllt. Dieser Statuscode soll Probleme durch <a href="Race_Condition" class="mw-redirect" title="Race Condition">Race Conditions</a> verhindern, indem eine Manipulation oder Löschen nur erfolgt, wenn der Client dies auf Basis einer aktuellen Ressource anfordert (Beispielsweise durch Mitliefern eines aktuellen <a href="HTTP_ETag" title="HTTP ETag">ETag-Header</a>).<a href="#cite_note-RFC6585-18">[18]</a>

</td></tr>

<th>429

</th>

<td>Too Many Requests

</td>

<td>Der Client hat zu viele Anfragen in einem bestimmten Zeitraum gesendet.<a href="#cite_note-RFC6585-18">[18]</a>

</td></tr>

<th>431

</th>

<td>Request Header Fields Too Large

</td>

<td>Die Maximallänge eines Headerfelds oder des Gesamtheaders wurde überschritten.<a href="#cite_note-RFC6585-18">[18]</a>

</td></tr>

<th>451

</th>

<td>Unavailable For Legal Reasons

</td>

<td>Dieser Statuscode soll darauf hinweisen, dass die angeforderte Ressource aufgrund von gesetzlichen Bestimmungen (Copyrighteinschränkungen, Zensur etc., eventuell <a href="Geoblocking" title="Geoblocking">beschränkt auf ein bestimmtes Land</a>) nicht verfügbar ist.<a href="#cite_note-19">[19]</a>

Er wurde im Juni 2012 von Google-Mitarbeiter <a href="Tim_Bray" title="Tim Bray">Tim Bray</a> bei der <a href="Internet_Engineering_Task_Force" title="Internet Engineering Task Force">IETF</a> eingereicht<a href="#cite_note-20">[20]</a> und gilt seit dem 17. Dezember 2015 als angenommen.<a href="#cite_note-21">[21]</a> Bray schlug die Nummer 451 in Anspielung auf <a href="Ray_Bradbury" title="Ray Bradbury">Ray Bradburys</a> Roman <a href="Fahrenheit_451" title="Fahrenheit 451">Fahrenheit 451</a> vor und fügte einen Dank an den Autor an.<a href="#cite_note-22">[22]</a>

</td></tr>

<tr>

<td colspan="3">Beispiele für weitere nicht in der Hypertext Transfer Protocol (HTTP) Status Code Registry<a href="#cite_note-status-code-registry-23">[23]</a> aufgeführte Codes:

</td></tr>

<th>418

</th>

<td><a href="Hyper_Text_Coffee_Pot_Control_Protocol" title="Hyper Text Coffee Pot Control Protocol">I’m a teapot</a>

</td>

<td>Dieser Code wurde von der <a href="Internet_Engineering_Task_Force" title="Internet Engineering Task Force">IETF</a> als <a href="Aprilscherz" title="Aprilscherz">Aprilscherz</a> in einem <a href="Request_for_Comments#Humor_in_RFC" title="Request for Comments">RFC</a> veröffentlicht. Innerhalb eines scherzhaften Protokolls zum Kaffeekochen, des <a href="Hyper_Text_Coffee_Pot_Control_Protocol" title="Hyper Text Coffee Pot Control Protocol">Hyper Text Coffee Pot Control Protocols</a>, zeigt er an, dass fälschlicherweise eine <a href="Teekanne" title="Teekanne">Teekanne</a> anstatt einer <a href="Kaffeekanne" title="Kaffeekanne">Kaffeekanne</a> verwendet wurde.<a href="#cite_note-24">[24]</a> Einige Server verwenden den Statuscode, um anzuzeigen, dass sie eine Anfrage nicht beantworten möchten, etwa bei automatisierten Anfragen. Durch die Verbreitung ist der Code mittlerweile nicht für andere Zwecke verwendbar.<a href="#cite_note-25">[25]</a> In der Status Code Registry ist der Code reserviert, allerdings als „Unused“ anstatt in der scherzhaften Bedeutung.<a href="#cite_note-status-code-registry-23">[23]</a>

</td></tr>

<th>420

</th>

<td>Policy Not Fulfilled

</td>

<td>In <a href="World_Wide_Web_Consortium" title="World Wide Web Consortium">W3C</a> PEP (Working Draft 21. November 1997)<a href="#cite_note-26">[26]</a> wird dieser Code vorgeschlagen, um mitzuteilen, dass eine Bedingung nicht erfüllt wurde.

</td></tr>

<th>444

</th>

<td>No Response

</td>

<td>In <a href="Nginx" title="Nginx">nginx</a>-Logs verwendet, um anzuzeigen, dass der Server keine Informationen zum Client zurückgesendet und die Verbindung geschlossen hat.

</td></tr>

<th>449

</th>

<td>The request should be retried after doing the appropriate action

</td>

<td>Genutzt in Antworten des <a href="Microsoft_Exchange_Server" title="Microsoft Exchange Server">Microsoft Exchange Servers</a>.<a href="#cite_note-27">[27]</a>

</td></tr>

<th>499

</th>

<td>Client Closed Request

</td>

<td>Ein nicht standardisierter Statuscode, der von <a href="Nginx" title="Nginx">nginx</a> für den Fall eingeführt wurde, dass ein Client die Verbindung schließt, während nginx die Anforderung verarbeitet.

</td></tr></tbody></table>

<div class="mw-heading mw-heading3"><h3 id="5xx_–_Server-Fehler"> 5xx – Server-Fehler</h3></div>

Nicht klar von den so genannten <a href="Client" title="Client">Client</a>-Fehlern abzugrenzen. Die Ursache des Scheiterns der Anfrage liegt jedoch eher im Verantwortungsbereich des Servers.

<th>Code

</th>

<th>Nachricht

</th>

<th>Bedeutung

</th></tr>

<th>500

</th>

<td>Internal Server Error

</td>

<td>Dies ist ein „Sammel-Statuscode“ für unerwartete Serverfehler.

</td></tr>

<th>501

</th>

<td>Not Implemented

</td>

<td>Die Funktionalität, um die Anfrage zu bearbeiten, wird von diesem Server nicht bereitgestellt. Ursache ist zum Beispiel eine unbekannte oder nicht unterstützte HTTP-Methode.

</td></tr>

<th>502

</th>

<td>Bad Gateway

</td>

<td>Der Server konnte seine Funktion als Gateway oder Proxy nicht erfüllen, weil er seinerseits eine ungültige Antwort erhalten hat.

</td></tr>

<th>503

</th>

<td>Service Unavailable

</td>

<td>Der Server steht temporär nicht zur Verfügung, zum Beispiel wegen Überlastung oder Wartungsarbeiten. Ein „Retry-After“-Header-Feld in der Antwort kann den Client auf einen Zeitpunkt hinweisen, zu dem die Anfrage eventuell bearbeitet werden könnte.

</td></tr>

<th>504

</th>

<td>Gateway Timeout

</td>

<td>Der Server konnte seine Funktion als Gateway oder Proxy nicht erfüllen, weil er innerhalb einer festgelegten Zeitspanne keine Antwort von seinerseits benutzten Servern oder Diensten erhalten hat.

</td></tr>

<th>505

</th>

<td>HTTP Version not supported

</td>

<td>Die benutzte HTTP-Version (gemeint ist die Zahl vor dem Punkt) wird vom Server nicht unterstützt oder abgelehnt.

</td></tr>

<th>506

</th>

<td>Variant Also Negotiates

</td>

<td>Die <a href="Content_Negotiation" title="Content Negotiation">Inhaltsvereinbarung</a> der Anfrage ergibt einen <a href="Zirkelbezug" title="Zirkelbezug">Zirkelbezug</a>.<a href="#cite_note-RFC2295-5">[5]</a>

</td></tr>

<th>507

</th>

<td>Insufficient Storage

</td>

<td>Die Anfrage konnte nicht bearbeitet werden, weil der Speicherplatz des Servers dazu derzeit nicht mehr ausreicht.<a href="#cite_note-RFC4918-7">[7]</a>

</td></tr>

<th>508

</th>

<td>Loop Detected

</td>

<td>Die Operation wurde nicht ausgeführt, weil die Ausführung in eine <a href="Endlosschleife_(Programmierung)" title="Endlosschleife (Programmierung)">Endlosschleife</a> gelaufen wäre. Definiert in der Binding-Erweiterung für WebDAV gemäß RFC 5842,<a href="#cite_note-RFC5842-11">[11]</a> weil durch Bindings zyklische Pfade zu WebDAV-Ressourcen entstehen können.

</td></tr>

<th>509

</th>

<td>Bandwidth Limit Exceeded

</td>

<td>Die Anfrage wurde verworfen, weil sonst die verfügbare Bandbreite überschritten würde (inoffizielle Erweiterung einiger Server).

</td></tr>

<th>510

</th>

<td>Not Extended

</td>

<td>Die Anfrage enthält nicht alle Informationen, welche die angefragte Server-Extension zwingend erwartet.<a href="#cite_note-RFC2774-6">[6]</a>

</td></tr>

<th>511

</th>

<td>Network Authentication Required

</td>

<td>Der Client muss sich zuerst authentifizieren, um Zugang zum Netzwerk zu erhalten.<a href="#cite_note-RFC6585-18">[18]</a>

</td></tr></tbody></table>

<div class="mw-heading mw-heading3"><h3 id="9xx_–_Proprietäre_Fehler"> 9xx – Proprietäre Fehler</h3></div>

Manche Softwarehersteller verwenden den Bereich ab 900 für <a href="Propriet%C3%A4r" title="Proprietär">proprietäre</a> Statuscodes.<a href="#cite_note-28">[28]</a>

Dieser Zahlenbereich wurde in den RFC-Dokumenten nie erwähnt und liegt offensichtlich jenseits der standardisierten Codes. Dadurch ist er leicht als Sonderfall erkennbar.

<div class="mw-heading mw-heading2"><h2 id="Siehe_auch">Siehe auch</h2></div>

<ul><li><a href="Fehlerseite" title="Fehlerseite">Fehlerseite</a></li>

<li><a href="Hypertext_Transfer_Protocol" title="Hypertext Transfer Protocol">Hypertext Transfer Protocol</a></li>

<li><a href="Header" title="Header">Header</a></li>

<li><a href="Liste_der_HTTP-Headerfelder" title="Liste der HTTP-Headerfelder">Liste der HTTP-Headerfelder</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<ul><li><a rel="nofollow" class="external text" href="https://www.iana.org/assignments/http-status-codes">Hypertext Transfer Protocol (HTTP) Status Code Registry.</a> <a href="Internet_Assigned_Numbers_Authority" title="Internet Assigned Numbers Authority">IANA</a></li>

<li><a rel="nofollow" class="external text" href="https://www.askapache.com/htaccess/apache-status-code-headers-errordocument/">apache-status-code-headers.</a> askapache.com</li>

<li>Roy Fielding, Julian Reschke: <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <style data-mw-deduplicate="TemplateStyles:r250917974">

/* start https://de.wikipedia.org/ */

.mw-parser-output .dewiki-iconexternal>a{background-position:center right!important;background-repeat:no-repeat!important}body.skin-minerva .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/OOjs_UI_icon_external-link-ltr-progressive.svg")!important;background-size:10px!important;padding-right:13px!important}body.skin-timeless .mw-parser-output .dewiki-iconexternal>a,body.skin-monobook .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/MediaWiki_external_link_icon.svg")!important;padding-right:13px!important}body.skin-vector .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/Link.ernal-small-ltr-progressive.svg")!important;background-size:0.857em!important;padding-right:1em!important}

/* end https://de.wikipedia.org/ */

</style><a href="https://datatracker.ietf.org/doc/html/rfc7231#section-6" class="extiw external" title="rfc:7231">7231</a> – Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. Juni 2014, Abschnitt 6: Response Status Codes. (englisch).</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-1"><a href="#cite_ref-1">↑</a> R. Fielding, M. Nottingham, J. Reschke: <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc9110" class="extiw external" title="rfc:9110">9110</a> – HTTP Semantics. Juni 2022 (englisch).

</li>

<a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc2616" class="extiw external" title="rfc:2616">2616</a> – HTTP 1.1. 1999 (englisch).

</li>

<a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc2518" class="extiw external" title="rfc:2518">2518</a> – HTTP Extensions for Distributed Authoring – WEBDAV. Februar 1999 (englisch).

</li>

<a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc2817" class="extiw external" title="rfc:2817">2817</a> – Upgrading to TLS Within HTTP/1.1. Mai 2000 (englisch).

</li>

<a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc2295" class="extiw external" title="rfc:2295">2295</a> – Transparent Content Negotiation in HTTP. März 1998 (englisch).

</li>

<a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc2774" class="extiw external" title="rfc:2774">2774</a> – An HTTP Extension Framework. Februar 2000 (englisch).

</li>

<a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc4918" class="extiw external" title="rfc:4918">4918</a> – HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). Juni 2007 (englisch).

</li>

<li id="cite_note-8"><a href="#cite_ref-8">↑</a> <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc8297" class="extiw external" title="rfc:8297">8297</a> – An HTTP Status Code for Indicating Hints. Dezember 2017 (englisch).

</li>

<li id="cite_note-9"><a href="#cite_ref-9">↑</a> Roy Fielding, Julian Reschke: <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc7231#section-6.3.4" class="extiw external" title="rfc:7231">7231</a> – Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. Juni 2014, Abschnitt 6.3.4: 203 Non-Authoritative Information. (englisch).

</li>

<li id="cite_note-10"><a href="#cite_ref-10">↑</a> Roy Fielding, Julian Reschke: <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc7230#section-5.7.2" class="extiw external" title="rfc:7230">7230</a> – Message Syntax and Routing. Juni 2014, Abschnitt 5.7.2: Transformations. (englisch).

</li>

<a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc5842" class="extiw external" title="rfc:5842">5842</a> – Binding Extensions to Web Distributed Authoring and Versioning (WebDAV). April 2010 (englisch).

</li>

<li id="cite_note-12"><a href="#cite_ref-12">↑</a> <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc3229" class="extiw external" title="rfc:3229">3229</a> – Delta encoding in HTTP. Januar 2002 (englisch).

</li>

<li id="cite_note-13"><a href="#cite_ref-13">↑</a> <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc1945" class="extiw external" title="rfc:1945">1945</a> – Hypertext Transfer Protocol – HTTP/1.0. Mai 1996 (englisch).

</li>

<li id="cite_note-14"><a href="#cite_ref-14">↑</a> Julian Reschke: <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc7538" class="extiw external" title="rfc:7538">7538</a> – The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). April 2015 (englisch).

</li>

</li>

<li id="cite_note-16"><a href="#cite_ref-16">↑</a> <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc8470" class="extiw external" title="rfc:8470">8470</a> – Using Early Data in HTTP. September 2018 (englisch).

</li>

<li id="cite_note-17"><a href="#cite_ref-17">↑</a> Roy Fielding, Julian Reschke: <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.15" class="extiw external" title="rfc:7231">7231</a> – Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. Juni 2014, Abschnitt 6.5.15: 426 Upgrade Required. (englisch).

</li>

<li id="cite_note-RFC6585-18">↑ <a href="#cite_ref-RFC6585_18-0">a</a> <a href="#cite_ref-RFC6585_18-1">b</a> <a href="#cite_ref-RFC6585_18-2">c</a> <a href="#cite_ref-RFC6585_18-3">d</a> <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc6585" class="extiw external" title="rfc:6585">6585</a> – Additional HTTP Status Codes. (englisch).

</li>

<li id="cite_note-19"><a href="#cite_ref-19">↑</a> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/draft-tbray-http-legally-restricted-status-00">A New HTTP Status Code for Legally-restricted Resources</a>

</li>

<li id="cite_note-20"><a href="#cite_ref-20">↑</a> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/draft-tbray-http-legally-restricted-status-00">tools.ietf.org</a>

</li>

<li id="cite_note-21"><a href="#cite_ref-21">↑</a> <a rel="nofollow" class="external text" href="https://datatracker.ietf.org/doc/draft-ietf-httpbis-legally-restricted-status/">datatracker.ietf.org</a>

</li>

<li id="cite_note-22"><a href="#cite_ref-22">↑</a> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/draft-tbray-http-legally-restricted-status-00#page-5">Appendix A</a>

</li>

</li>

<li id="cite_note-24"><a href="#cite_ref-24">↑</a> <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc2324" class="extiw external" title="rfc:2324">2324</a> – Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). 1. April 1998 (englisch).

</li>

<li id="cite_note-25"><a href="#cite_ref-25">↑</a> R. Fielding, M. Nottingham, J. Reschke: <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc9110#section-15.5.19" class="extiw external" title="rfc:9110">9110</a> – HTTP Semantics. Juni 2022, Abschnitt 15.5.19: 418 (Unused). (englisch).

</li>

<li id="cite_note-26"><a href="#cite_ref-26">↑</a> <a rel="nofollow" class="external text" href="https://www.w3.org/TR/WD-http-pep">w3.org</a> W3C PEP (Working Draft 21. November 1997)

</li>

<li id="cite_note-27"><a href="#cite_ref-27">↑</a> <a rel="nofollow" class="external text" href="https://blogs.msdn.microsoft.com/openspecification/2011/06/09/exchange-activesync-provisioning/">Microsoft Open Specifications Support Team Blog.</a> <a href="Microsoft_Developer_Network" title="Microsoft Developer Network">MSDN</a>. Abgerufen am 2. Mrz. 2016

</li>

<li id="cite_note-28"><a href="#cite_ref-28">↑</a> Beispielsweise liefert Linkedin bei Zugriff via <code>curl</code> den Code 999: <code style="white-space:nowrap">curl -kI https://www.linkedin.com/company/linkedin/</code> (<a rel="nofollow" class="external text" href="https://stackoverflow.com/questions/27231113/999-error-code-on-head-request-to-linkedin">vgl. Stackoverflow</a>)

</li>

</ol></div></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2026-01-13" href="https://de.wikipedia.org/wiki/?title=HTTP-Statuscode&oldid=263298242">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>